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ABSTRACT 

With  the  advent  of  distributed  computing  systems,  the  problem  of 
deadlock,  -which  has  been  essentially  solved  for  centra ized  computing  systems, 
has  reappeared.  Existing  centralized  deadlock  detection  techniques  are  either 
too  expensive  or  they  do  not  work  correctly  in  distributed  computing  systems. 
Although  several  algorithms  have  been  developed  speciJically  for  distributed  sys- 
tems, the  majority  of  them  have  also  been  shown  to  be  inefficient  or  incorrect.  A 
new  algorithm  is  proposed  which  is  more  efficient  than  any  existing  distributed 
deadlock  detection  algorithm. 

/.  INTRODUCTION 

Deadlock  is  a  circular  wait  condition  which  can  occur  in  any  multiprogramming, 
multiprocessing  or  distributed  computer  system  which  uses  locking  if  resources 
are  requested  when  needed  and  processes  are  not  assigned  priorities.  It  indi- 
cates a  state  in  which  each  member  of  a  set  of  transactions  is  waiting  for  some 
other  member  of  the  set  to  give  up  a  lock.  An  example  of  a  simple  deadlock  is 
shown  in  Figure  1.  Transaction  Tl  holds  a  lock  on  resource  Rl  and  requires 
resource  R2;  transaction  T2  holds  a  lock  on  resource  R2  and  requires  Rl.    Nei- 


ther  transaction  can  proceed,  and  neither  will  release  a  lock  unless  forced  by 
some  outside  agent.  There  have  been  many  algorithms  published  for  deadlock 
detection,  prevention  or  avoidance  in  centralized  multiprogramming  systems. 
The  problem  of  deadlock  in  those  systems  has  been  essentially  solved.  With  the 
advent  of  distributed  computing  systems,  however,  the  problem  of  deadlock 
reappeared.  Certain  peculiarities  of  distributed  systems  (lack  of  global  memory 
and  non-neglibible  message  delays,  in  particular)  make  centralized  techniques 
for  deadlock  detection  expensive.  Recently  there  have  been  published  several 
deadlock  detection  algorithms  for  distributed  systems  [OBE82,  GLI80,  MEN79, 
GRA73.  TSA82].  However,  most  of  them  have  been  shown  to  be  incorrect  or  to  be 
too  complex  and  expensive  to  be  practical.  In  this  paper,  we  propose  a  new  dis- 
tributed deadlock  detection  algorithm  for  distributed  computing  systems  which 
is  more  efficient  than  any  other  published  deadlock  detection  algorithm.  The 
major  differences  between  the  proposed  algorithm  and  existing  algorithms  are 
the  concept  of  a  Lock  History  which  each  transaction  carries  with  it,  the  notion 
of  Intention  Locks  and  a  three  staged  approach  to  deadlock  detection,  with  each 
stage,  or  level,  of  detection  activity  being  more  complex  than  the  preceding.  In 
this  paper,  we  first  present  the  algorithm,  then  an  informal  proof  of  correctness, 
and  finally  a  performance  comparison  of  the  proposed  algorithm  with  the  algo- 
rithm presented  in  [OBE82].  Obermarck's  algorithm  is  used  for  comparison  for 
two  reasons.  First,  it  is  the  most  recently  published  distributed  deadlock  detec- 
tion algorithm  and  it  is  also  shown  to  be  more  efficient  than  other  algorithms. 


Tl  T2 
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Fig.  1  --  A  simple  deadlock  cycle 


Second,  Obermarck's  algorithm  is  being  implemented  on  IBM's  distributed  data- 
base System  R*. 

//    THE  PROPOSED  ALGORITHM 

A.   INTRODUCTION 

The  proposed  algorithm  assumes  two  types  of  Locks:  Exclusive  Write(W)  and 
Shared  Read(R).  Additionally,  the  proposed  algorithm  uses  an  Intention  Lock  (I) 
which  indicates  that  a  transaction  wishes  to  acquire  a  lock  on  a  resource,  either 
to  modify  it  (IW)  or  to  read  it  (IR).  The  Intention  Locks  are  piaced  in  a  resource 
Lock  Table  when  an  agent  is  created  at  a  site  of  a  locked  resource  which  it 
requires,  or  when  a  resource  at  the  same  site  is  requested  but  is  already  locked 
by  another  transaction.  The  Intention  Locks  are  also  placed  in  the  Lock  Table  of 
the  :ast  locked  resource(s)  once  the  transaction  can  determine  which 
resc\j-ce(s;  intends  to  lock  in  its  next  execution  step.  The  Intention  Locks  are 
not  the  sane  as  the  Intention  Modes  used  by  Gray  when  he  discusses  hierarchi- 
cal locks  in.  [GRA78].  Gray  uses  the  Intention  Mode  to  "tag"  ancestors  of  a 
resource  ir.  a  hierarchical  set  of  resources  as  a  means  of  indicating  that  locking 
is  being  done  on  a  "finer"  level  of  granularity,  and  therefore  preventing  locking 
on  the  ancestors  of  the  resource.  The  rules  for  locks  in  the  proposed  algorithm 
are  the  same  as  for  conventional  locking,  i.e.,  any  number  of  transactions  or 
agen-s  may  simultaneously  hold  Shared  Read  Locks  on  a  particular  resource, 
but  only  a  single  transaction  or  agent  may  hold  an  Exclusive  Write  Lock  on  a 
resource.  Any  number  of  Intention  Locks  (I¥  or  IR)  may  be  placed  on  a 
resource,  which  means  that  any  number  of  transactions  may  wait  for  a  resource. 
Each  site  must  therefore  have  some  method  for  determining  which  transaction 
will  be  given  the  resource  when  it  becomes  free.  Our  algorithm  uses  Lock  His- 
tory (LH)  of  a  transaction  which  is  a  record  of  all  types  of  locks  on  any  resources 


which  have  been  requested  or  are  held  by  that  transaction.  An  example  of  a 
Lock  History  for  transaction  Tl  is  LH(Tl):  $W(R3C),  W(R2B),  R(R1A)J.  This  LH 
shows  that  Tl  holds  a  Write  Lock  on  resource  R3  at  site  C,  a  Write  Lock  on 
resource  R2  at  site  B,  and  a  Read  Lock  on  resource  Rl  at  site  A.  The  information 
contained  in  a  Lock  Table  for  a  resource  includes  a)  the  transaction  or  agent  ID 
and  its  Lock  History,  b)  the  type  of  lock  and  c)  the  resource  (and  type  of  lock) 
which  that  transaction  holding  this  lock  intends  to  lock  next.  The  field  contain- 
ing the  current  lock  will  be  referred  to  as  the  "current"  field  of  the  Lock  Table, 
and  the  field  containing  the  future  intentions  of  that  transaction  holding  the 
"current"  look  will  be  called  the  "Next"  field.  For  clarity,  Lock  Histories  will  be 
shown  as  separate  entities.  An  example  of  a  Lock  Table  is  LT(R2B):  T1*W(R2B), 
IW(R3C)j;  T2$IW(R2B){.  The  Lock  Table  for  resource  R2  at  site  B  shows  that  Tl 
holds  a  Write1  Lock  on  R2.  and  that  T2  has  placed  an  Intention  Write  Lock  on  R2. 
Tl  has  also  iidicated  that  it  intends  to  place  a  Write  Lock  on  resource  R3  at  site 
C.  The  proposed  algorithm  assumes  a  distributed  model  of  transaction  execu- 
tion where  each  transaction  has  a  Site  of  Origin  (Sorig),  which  is  the  site  at 
which  it  entered  the  system.  Whenever  a  transaction  requires  a  remote 
resource,  (a  resource  at  a  site  other  than  the  site  it  is  currently  at),  it 
"migrates"  to  the  site  where  that  resource  is  located.  Migration  consists  of 
creating  an  "agent"  at  the  new  site.  The  transaction  agent  then  executes,  and 
may  either  create  additional  agents,  start  commit  or  abort  actions,  or  return 
execution  to  the  site  from  which  it  migrated.  This  transaction  model  is  con- 
sistent with  recent  literature  [OBE82,  GRAB  IB].  When  a  transaction  migrates,  it 
carries  along  its  Lock  History.  A  Wait-For  Graph  (WFG)  is  constructed  by  the 
deadlock  detection  algorithm,  using  the  Lock  Histories  of  transactions  which  are 
possibly  involved  in  a  deadlock  cycle,  any  time  a  transaction  or  agent  attempts 
to  place  a  lock  on  a  resource  which  is  already  locked,  or  when  it  determines  that 
a  remote  resource  will  be  required.    There  are  two  types  of  nodes  in  the  WFG; 


transactions  (or  agents)  and  resources.  A  directed  arc  from  a  resource  node  to 
a  transaction  node  indicates  that  the  transaction  has  a  lock  on  the  resource, 
while  a  directed  arc  from  a  transaction  node  to  a  resource  indicates  that  the 
transaction  has  placed  an  Intention  Lock  on  that  resource.  A  cycle  in  the  7WG 
indicates  the  existence  of  the  deadlock.  The  WS  is  a  list  of  transaction  -  waits  - 
for  -  transaction  strings  (obtained  from  the  site's  WFG),  in  which  each  transac- 
tion is  waiting  for  the  next  transaction  in  the  string,  and  the  Lock  History  for 
each  transaction  in  the  string.  For  example,  the  WFS  [T1[W(R2A),  IW(R3B)j, 
T4$W(R3B)J]  shows  that  Tl  is  waiting  for  T4,  and  each  transaction's  Lock  History 
is  in  brackets.  A  transaction  may  also  bring  along  other  information  such  as  a 
metric  representing  its  execution  cost,  but  such  information  is  not  included  in 
this  paper  as  it  is  outside  the  primary  function  of  the  proposed  deadlock  detec- 
tor. We  assume  that  each  transaction  or  agent  will  have  a  globally  unique 
identifier  which  indicates  its  Site  of  Origin.  Agents  can  be  in  any  of  three  states; 
active,  blocked  (waiting),  or  inactive.  An  inactive  agent  is  one  which  has  done 
work  at  a  site  and  created  an  agent  at  another  site  or  returned  execution  to  its 
creating  site,  and  is  now  awaiting  further  instructions,  such  as  commit,  abort  or 
become  active  again.  A  blocked  transaction  is  one  which  has  requested  a 
resource  which  is  locked  by  another  transaction  An  active  agent  is  one  which  is 
not  blocked  or  inactive.  To  allow  concurrent  execution,  a  transaction  may  have 
several  active  agents.  Each  site  in  the  system  has  a  distributed  deadlock  detec- 
tor, which  performs  deadlock  detection  for  transactions  or  agents  at  that  site. 
Several  sites  can  simultaneously  be  working  on  detection  of  any  potential 
deadlock  cycle.  The  basic  premise  of  the  proposed  algorithm  is  to  detect 
deadlock  cycles  with  the  least  possible  delay  and  number  of  inter-site  messages. 
Based  on  the  findings  by  Gray  and  others  [GRA81A]  that  cycles  of  length  2  occur 
much  more  frequently  that  cycles  of  length  3,  and  cycles  of  length  3  occur  much 
more  frequently  that  cycles  of  length  4,  and  so  on  the  proposed  algorithm  uses 


a  staged  approach  to  deadlock  detection.  We  distinguish  two  types  of  deadlock 
cycles  to  be  considered;  a)  those  which  can  be  detected  using  only  the  informa- 
tion available  at  a  site,  and  b)  those  which  require  inter-site  messages  to  detect. 
In  the  proposed  algorithm,  the  first  type  has  been  divided  into  two  levels  of 
detection  activity.  Because  the  proposed  algorithm  checks  for  possible 
deadlock  cycles  every  time  a  remote  resource  is  requested  and  another  transac- 
tion is  waiting  for  a  resource  being  released  by  the  transaction  making  the 
remote  resource  request  or  a  local  resource  is  requested  but  already  locked, 
the  level  one  check  should  be  as  quick  as  possible.  If  the  requested  resource  is 
still  not  available  "after  X  units  of  time"  [GRA7B],  then  the  probability  of  a 
deadlock  has  increased  sufficiently  to  justify  a  more  complex  and  time- 
consuming  check  in  level  two.  Therefore  the  proposed  algorithm  has  three  lev- 
els of  deadlock  detection  activity.  Levels  one  and  two  correspond  to  the  first 
type  of  deadlock  cycle,  while  level  three  corresponds  to  the  second  type.  The 
first  level  is  designed  to  detect  cycles  of  leng;h  2,  although  certain  more  com- 
plex deadlock  cycles  could  be  detected,  depending  on  the  topology  of  the 
deadlock  cycle.  This  level  uses  only  information  available  in  the  Lock  Table  of 
the  requested  resource  if  the  resource  Ls  local,  or  the  last  locked  resource  if  the 
requested  resource  is  at  another  site,  and  in  the  transaction  Lock  Histories. 
Due  to  the  information  contained  in  the  "Next"  field  of  the  Lock  Table  and  in 
each  transaction's  Lock  History,  this  level  of  detection  activity  can  detect  all 
direct  deadlocks  of  cycle  length  2  involving  one  or  two  sites.  The  deadlock  is 
direct  if  at  least  one  transaction  is  blocked,  i.e.,  is  waiting  for  the  resource  R 
locked  by  another  transaction  T'  and  R  is  the  last  resource  locked  by  T  before  it 
becomes  blocked  too.  The  direct  deadlocks  occur  mostly  due  to  locks  being 
released  after  the  transaction  does  not  require  the  resource  any  more.  The 
indirect  deadlocks  can  occur  when  the  resources  are  kept  locked  until  the  tran- 
saction termination  as  is  done  in  database  systems  which  use  two-phase  locking. 
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As  an  example,  let  transaction  Tl  at  site  A  Write  Lock  resource  Rl.  Let  transac- 
tion T2  at  site  B  Write  Lock  resource  R2.  These  locks  would  be  placed  in  the  Lock 
Tables  of  the  respective  resources,  and  also  in  the  Lock  Histories  for  the  respec- 
tive transactions.  Transaction  Tl  now  determines  that  it  must  lock  a  remote 
resource  R2,  so  it  places  that  information  in  the  "Next"  field  of  its  lock  entry  of 
resource  Rl  and  in  its  Lock  History.  It  then  migrates  to  site  B,  where  its  agent 
places  an  Intention  Lock  in  the  Lock  Table  for  R2,  and  then  becomes  blocked. 
waiting  for  resource  R2  to  be  released.  A  le^el  one  check  is  made  using  the  Lock 
Table  of  R2,  showing  no  deadlock  cycles.  Now  transaction  T2  determines  that  it 
requires  a  Write  Lock  on  a  remote  resource  Rl.  It  places  that  information  in  the 
"Next"  field  of  its  lock  entry  in  the  Lock  Taole  of  R2  and  in  its  Lock  History.  As 
Tl  is  waiting  for  R2  a  deadlock  detector  triggers  level  one  of  the  deadlock  detec- 
tion algorithm  before  T2  migrates  to  site  A.  The  deadlock  detection  algorithm 
combines  the  Lock  Histories  of  all  transactions  holding  or  requesting  locks  on  R2 
(Tl  and  T2)  into  a  WFG.  and  detects  a  deadlock.  In  this  example,  the  cost  of 
creating  an  agent  of  T2  at  site  A  was  saved  by  a  very  quick  check  for  cycles  of 
length  two.  Inasmuch  as  the  majority  of  deadlocks  occurring  will  be  of  this 
length,  this  simple  and  inexpensive  check  ^rill  detect  the  majority  of  deadlocks 
as  they  occur.  If,  in  the  example  just  given,  transactions  Tl  and  T2  had  simul- 
taneously determined  the  need  for  locks  at  the  other  site,  the  initial  level  one 
check  would  not  have  been  performed  because  no  transactions  were  waiting  for 
those  resources.  Both  transactions  would  have  migrated  and  placed  Intention 
Locks  at  the  new  sites.  A  level  one  check  is  then  made  at  each  site  when  it  is 
noted  that  the  requested  resource  is  not  available.  Each  site  constructs  a  WFG 
from  the  Lock  Histories  of  the  transactions  in  the  Lock  Tables  of  the  requested 
resources,  and  each  site  will  detect  a  deadlock  cycle  in  the  WFG  without  any 
inter-site  messages.  Even  if  the  first  level  of  detection  activity  fails  to  detect  a 
deadlock  cycle,  there  can  still  be  a  more  complex  deadlock  cycle  in  existence. 


The  second  level  of  detection  activity  requires  more  time  because  it  constructs 
a  WG  using  all  Lock  information  available  at  the  site,  i.e.,  Lock  information  from 
all  resource  Lock  Tables  at  the  site.  If  we  assume  that  more  complex  deadlock 
cycles  are  comparatively  rare,  it  is  advantageous  to  "wait  X  units  of  time" 
[GRA78]  before  starting  the  second  level  of  detection  activity.  If  a  transaction 
is  still  waiting  to  acquire  a  lock  after  these  X  units  of  time,  the  probability  of  a 
more  complex  deadlock  cycle  existing  has  increased  sufficiently  to  justify  a 
more  comprehensive  check.  As  previously  mentioned,  the  second  level  still 
attempts  to  detect  a  cycle  using  information  available  at  the  same  site  where 
the  transaction  is  waiting  for  a  resource.  The  Lock  Histories  of  all  blocked  or 
inactive  transactions  at  the  site,  and  the  Lock  Histories  from  all  transactions  in 
the  WFSs  from  other  sites  are  combined  into  a  new  Wait-For  Graph.  (The  WS's 
are  generated  by  the  third  level  of  the  proposed  algorithm).  If  no  deadlock  is 
detected,  and  because  level  three  of  deadlock  detection  activity  involves  inter- 
site  communication,  it  might  be  advantageous  to  wait  Y  units  of  time  before  con- 
tinuing in  order  to  increase  the  probability  of  the  wait  condition  being  an  actual 
deadlock.  After  Y  units  of  time,  when  the  deadlock  detection  algorithm  is  ready 
to  continue,  the  WG  is  converted  into  a  WS.  The  WS  is  then  sent  to  other 
sites.  The  version  of  the  algorithm  presented  here  includes  an  optimization 
whereby  the  WS  is  sent  to  the  site  to  which  the  transaction  being  waited  for  has 
migrated  only  if  the  first  transaction  in  the  WS  has  a  higher  lexical  ordering 
than  the  transaction  which  has  migrated.  This  optimization  is  similar  to  one 
used  in  [0BE82].  When  a  site  deadlock  detector  receives  a  WS,  it  substitutes 
the  latest  Lock  Histories  for  any  transaction  for  which  it  has  a  later  version  (the 
longest  Lock  History  is  the  latest).  It  then  constructs  a  new  WFG  and  checks  for 
cycles.  If  a  cycle  is  found,  it  must  be  resolved.  If  any  transactions  are  waiting 
for  other  transactions  which  have  migrated  to  other  sites,  the  current  site  must 
repeat  the  process  of  constructing  WFG's  and  sending  them  to  the  sites  to  which 


B 


the  transactions  being  waited  for  have  migrated,  subject  to  the  constraints  of 
the  optimization.  If  the  transactions  being  waited  for  are  at  this  site  and  active. 
deadlock  detection  activity  can  cease.  Level  three  activity  will  continue  until  a 
deadlock  is  found  or  it  is  discovered  that  there  is  no  deadlock.  The  following 
definitions  are  used  in  the  description  of  the  algorithm: 

IL  —  Intention  Lock 

W(v)  —  Exclusive  Write  lock  on  resource  x 
R(x)  -  Shared  Read  lock  on  resource  x 
IW(x)  —  IntentioD  Lock(Write)  on  resource  x 
IR(x)  —  Intention  Lock(Read)  on  resource  x 
Sorig(T)  —  Site  or  Origin  of  transaction  T 
LT(R)  -  Lock  Table  for  resource  R 
LH(T)  —  Lock  History  for  transaction  T 

"Next"  -  Field  in  Lock  Table  reflecting  the  resource  the  transaction  intends  to 
acquire  next 

"Current"  —  Field  in  Lock  Table  reflecting  the  lock  currently  held  by  a  transac- 
tion 

B.  THE  ALGORITHM 

1.  {Remote  resource  R  requested  or  anticipated  by  transaction  or  agent 

T{ 

A.  Place  appropriate  IL  entry  in  "next"  field  of  the  Lock  Table  of 
the  current  resource  (the  last  resource  locked  bv  T.if  any)  and  in 
LH(T). 

B.  I  Start  level  1  detection  activity  at  current  site}.  If  another 
transaction  is  waiting  for  the  last  resource  locked  by  T,  construct 
a  Wait-For  graph  and  WFS  from  the  Lock  Histories  of  the  transac- 
tions holding  and  requesting  that  resource  and  check  for  cycles. 

C.  If  no  cycles  are  detected  or  if  no  transactions  are  waiting: 

1)  Collect  LH(T)  and  the  WFS  (generated  at  step  l.B)  from 
the  current  site,  and  have  an  agent  created  at  the  site  of  the 
requested  resource. 

2)  Stop 

D.  If  a  cycle  is  detected,  resolve  the  deadlock 

2.  {Local  resource  R  requested} 

A.  If  resource  R  is  available:  [Lock  it{ 

1)  Place  appropriate  lock  in  Lock  Table  of  resource  R  and 
inLH(T). 
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2)  end 
B.  If  resource  is  not  available:  $Start  level  1  detection  activity} 

1)  Place  appropriate  IL  in  Lock  Table  of  resource  R  and  in 
LH(T). 

2)  Construct  a  WF  Graph  from  Lock  Histories  of  all  tran- 
sactions holding  and  requesting  R,  and  check  for  cycles. 

3)  If  there  are  no  cycles,  and  if  the  transaction  holding 
the  lock  on  R  is  still  at  this  site  and  active,  stop.  If  there 
is  a  cycle,  resolve  the  deadlock. 

4)  If  the  transaction  holding  the  lock  on  R  has  either 
migrated  to  another  site,  or  is  still  at  this  site  but  is 
blocked  by  another  transaction  which  has  migrated  to 
another  site,  delay(tl). 

5)  If  resource  is  now  available: 

a)  Remove  IL  from  Lock  Table  and  LH(T) 

b)  Go  to  step  2A 

6)  If  resource  is  not  available:  $Start  level  2  activity} 

a)  Construct  a  WFG  using  the  Lock  Histories  of  the 
transactions  in  the  WFSs  which  have  been  sent  from  other 
sites  by  level  three  detection  activity,  and  the  Lock  His- 
tories of  all  blocked  or  inactive  transactions  at  this  site 
and  check  for  cycles. 

b)  If  any  cycles  are  found,  resolve  the  deadlock. 

c)  If  no  cycles  are  found.  Delay(t2) 

d)  If  the  requested  resource  is  now  available,  go  to 
step  2A 

e)  If  the  transaction  being  waited  for  is  at  this  site 
and  active,  stop. 

f)  If  the  resource  is  still  not  available,  go  to  step  3 
$Start  level  3  detection  activity}. 


3.   [Wait-For  Message  Generation} 

A.   JStart  Level  3  detection  activity}  Construct  a  WFS  by  condens- 
ing the  latest  WFG  into  a  list  of  strings  of  transactions  waiting  for 
transactions.    Add  the  Lock  Histories  of  each  transaction  in 
string. 
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B.  Send  the  WFS  to  the  site  to  which  the  transaction  being  waited 
for  has  gone  if  the  transaction  being  waited  for  in  each  substring 
has  a  smaller  identifier  than  the  first  transaction  in  that  sub- 
string. 

4.  $Wait-For  Message  Received} 

A.  \  Start  level  3  detection  activity}  Construct  a  WFG  from  the 
Lock  Histories  of  the  transactions  in  the  WFS's  from  other  sites, 
and  from  the  Lock  Histories  of  all  blocked  or  inactive  transac- 
tions at  this  site.  (Use  the  latest  WFS  from  each  site.) 

B.  If  this  WFG  shows  that  a  transaction  which  is  being  waited  for 
has  migrated  to  another  site,  go  to  step  3.  ^Repeat  WFS  Genera- 
tion} 

C.  If  the  transaction  being  waited  for  is  active,  and  has  not  indi- 
cated by  an  Intention  Lock  that  it  will  attempt  to  acquire  a 
resource  which  may  result  in  a  deadlock,  discard  the  WFG  and 
stop. 

D.  If  the  transaction  being  waited  for  is  active  but  has  indicated 
by  an  Intention  Lock  that  it  is  going  to  a  site  which  will  cause  a 
deadlock,  or  if  a  cycle  is  found,  resolve  the  deadlock. 

C.   EXPLANATION  OF  THE  ALGORITHM 

Step  1.  This  step  is  executed  any  time  a  transaction  (or  agent)  T  requests  a 
remote  resource,  or  when  it  determines  that  it  will  require  a  remote  resource. 
The  Lock  Table  of  the  resource  which  the  transaction  is  currently  using  (or  has 
just  finished  with)  is  checked  to  see  if  any  other  transactions  are  waiting  (i.e., 
have  placed  Intention  Locks)  for  that  resource.  If  so,  the  Lock  Histories  of  all 
transactions  requesting  and  holding  the  resource  are  combined  into  a  WFG  and  a 
check  for  cycles  is  made.  If  no  cycle  is  found,  T  collects  the  WFS  formed  from 
the  WFG  at  that  site  and  causes  an  agent  to  be  created  at  the  site  of  the 
requested  resource.  Step  2.  This  step  is  executed  each  time  a  local  resource  is 
requested,  either  by  an  agent  (transaction)  already  at  that  site  or  by  a  newly 
created  agent.  If  the  resource  is  available,  appropriate  locks  are  placed  and  the 
resource  granted.  If  the  resource  is  not  available,  Intention  Locks  are  placed  in 
the  Lock  Table   of  the   requested  resource  and  in  the  Lock  History  of  the 
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requesting  transaction,  a  WFG  is  constructed  using  only  the  information  in  the 
Lock  Table  of  the  requested  resource  and  the  Lock  Histories  of  the  transactions 
holding  or  requesting  that  resource,  and  a  quick  level  one  check  is  made  for  pos- 
sible deadlock  cycles.  If  no  cycles  are  found,  the  algorithm  waits  for  a  certain 
period  of  time  before  continuing.  This  should  allow  the  transaction  which  holds 
the  resource  to  complete  its  work  and  release  the  resource.  If  the  resource  is 
not  available  after  this  delay,  the  chance  of  a  deadlock  is  higher,  so  the  algo- 
rithm shifts  to  another  level  of  detection.  It  now  uses  the  Lock  Plistories  from 
each  blocked  or  inactive  transaction  at  the  site,  as  well  as  from  any  WFS's  from 
other  sites  which  have  been  brought  by  migrating  transactions.  If  there  are  no 
cycles  in  this  graph,  and  the  resource  is  still  not  available  after  a  second  delay 
(also  tunable  by  the  system  users),  the  possibility  of  deadlock  is  again  much 
greater,  but  the  current  site  has  insufficient  information  to  detect  it.  Therefore 
the  proposed  algorithm  progresses  to  the  third  level  of  detection  (step  3).  Step 
3.  The  Wait-For  message  generated  by  this  step  consists  of  a  collection  of  sub- 
strings. Each  substring  is  a  list  of  transactions  each  of  which  is  waiting  for  the 
next  transaction  in  the  substring.  The  substring  also  contains  che  resources 
Locked  or  Intention  Locked  by  each  transaction  in  the  substring.  This  step 
includes  the  optimization  that  a  WFS  is  only  sent  to  another  site  .if  the  transac- 
tion which  has  migrated  has  a  lower  lexical  ordering  than  the  first  transaction  in 
the  substring.  For  example,  for  the  WFG  shown  in  Figure  2,  the  WFS  would  be 
[T2SW(R2B).IW(R3C)j,  T3fW(R3C),  IW(R4D)j,  T4$W(R4D),IW(R1A)}].  T4  has  migrated 
to  site  A.  The  WFS  would  be  sent  to  site  A  only  if  T4  is  less  than  T2. 

T4  T3  T2 

^\  S\  S\ 

R1A  R4D  R3C  R2B 

Fig.  2  -  Example  WFG 
Step  4.   In  this  step,  the  Lock  Histories  of  the  transactions  in  the  WFS's  previ- 
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ously  received  from  other  sites,  and  the  Lock  Histories  of  any  blocked  or  inac- 
tive transactions  at  this  site  are  added  to  the  Wait-For  information  contained  in 
a  received  "WFS.  If  there  is  still  insufficient  information  to  detect  a  cycle  (a  tran- 
saction being  waited  for  has  migrated  to  another  site),  another  iteration  must 
be  performed,  so  the  algorithm  repeats  by  transferring  to  step  3.  If  a  cycle  is 
detected,  it  is  resolved,  and  if  the  last  transaction  being  waited  for  is  still  active, 
the  algorithm  stops. 

D.   OPERATION  OF  THE  ALGORITHM 

Ihe  operation  of  the  algorithm  will  be  shown  by  executing  it  on  the  following 
example.  Tl  migrates  to  site  B  and  locks  resource  R2.  It  then  migrates  to  site  C 
and  locks  resource  R3.  T4  locks  resource  R4  at  site  D.  At  this  point,  the  Lock 
rlistories  and  Lock  Tables  are  as  in  Fig.  3. 

Tl  now  attempts  to  acquire  resource  R4.    By  step  1,  an  IL  entry  is  placed  in 

Site  A 

LH(T1):  |IW(R2B)J 
SiteB 

LH(T1):  |W(R2B),IW(R3C){ 

LT(R2B):  T1*W(R2B)J 
Site  C 

LH(T1):  $W(R2B),W(R3C)1 

LT(R3C):  T1|W(R3C)J 
SiteD 

LH(T4):  $W(R4D)J 

LT(R4D):  T4$W(R4D)J 

Fig.  3    Lock  Histories  and  Lock  Tables 
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LH(T1)  and  in  LT(R3)  at  site  C.  As  there  are  no  Intention  Locks  in  LT(R3C),  the 
WFS  from  site  C  is  collected  (at  this  point  in  time,  none  exists),  and  an  agent  of 
Ti  is  created  at  site  D,  with  Tl  "bringing"  LH(T1):  [W(B2B),  W(R3C),  1W(R4D)J. 
Site  D  now  applies  step  2B1.  and  places  the  H.  entry  in  LT(R4D)  and  LH(Ti).  Then 
it  executes  step  2B2  by  combining  the  Lock  Histories  of  Tl  and  T4.  No  cycles  are 
found,  but  as  T4  is  still  active  at  site  D,  the  DDA  is  stopped.  The  current  status 
of  the  Lock  Tables  and  Lock  Histories  is  as  in  Fig.  4.  T4  now  determines  that  it 
needs  to  write  into  resource  R3.  It  applies  step  1  and  places  an  IL  entry  in 
LH(T4)  and  LT(R4D).  The  Lock  Table  for  R4  is  now  LT(R4D):  T4|W(R4D),IW(R3C)J; 
TUlW(R4D)i.  and  the  Lock  History  for  T4  is  now  LH(T4):  *W(R4D),  IW(R3C)$.  It 
sees  in  LT(R4D)  that  Tl  is  waiting  for  R4,  so  it  combines  its  Lock  History  with 
Tl's.  This  reflects  the  cycle  Tl— >T4->T1,  so  a  deadlock  has  been  detected  with 
no  intersite  messages. 

Site  A 
LH(T1):  {IW(R2B)J 

SiteB 

LH(T1):  $W(R2B),IW(R3C)J 

LT(R2B):  Tl£W(R2B)i 
Site  C 

LH(T1):  |W(R2B),W(R2C),IW(R4D)j 

LT(R3C):  T1J"W(R3C).IW(R4D)J 

SiteD 

LH(T4):  }W(R4D)J 

LH(T1):  |W(R2B),W(R3C),IW(R4D)| 

LT(R4D):  T4$W(R4D);T1$IW(R4D)} 

Fig.  4  Lock  Tables  and  Lock  Histories 
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///.  INFORMAL  PROOF  OF  CORRECTNESS 

In  general,  a  deadlock  cycle  can  have  many  different  topologies.  For  the  model 
of  transaction  execution  used  in  the  proposed  algorithm  (migration  of  agents  of 
transactions),  these  different  topologies  can  be  loosely  grouped  into  four 
categories.  Category  A  involves  local  deadlocks  in  which  all  the  resources  and 
transactions  involved  in  the  deadlock  are  local,  i.e.,  located  at  one  site,  and  thus 
the  transactions  involved  have  not  locked  any  resources  at  other  sites. 
Category  B  is  the  same  as  category  A.  with  the  exception  that  the  trans  actions 
are  nonlocal,  i.e.,  they  may  have  locked  resources  at  other  sites  Category  C 
contains  direct  deadlocks  of  cycle  length  two  involving  only  one  transaction  and 
one  resource  at  each  of  two  sites.  Category  D  is  a  generalization  of  category  C 
deadlocks;  any  number  of  transactions  and  resources  may  bo  direotly  or 
indirectly  deadlocked  at  any  number  of  sites.  For  each  category,  it  will  be 
argued  that  the  algorithm  detects  all  possible  deadlocks  in  that  category,  and 
that  the  algorithm  does  not  detect  "false"  deadlocks  except  in  the  iase  T.'>nere  a 
transaction  which  was  involved  in  a  deadlock  has  aborted,  but  its  agen:s  have 
not  yet  been  notified.  If  all  the  transactions  and  resources  iivolved  in  a 
deadlock  are  located  at  the  same  site  and  none  of  the  transactions  have  locked 
resources  at  other  sites,  each  transaction's  Lock  History  will  be  an  accurate  and 
complete  snapshot  of  the  locks  placed  by  that  transaction.  If  the  deadlock  cycle 
length  is  two,  the  combination  of  the  Lock  Histories  in  step  ZBZ  (level  l)  will 
detect  the  cycle.  If  the  length  of  the  cycle  is  greater  than  two,  step  2B6  (level  2) 
will  combine,  for  this  category  of  deadlock  cycles,  the  Lock  Histories  of  all  the 
blocked  or  inactive  transactions  at  the  site.  This  information  will  be  a  complete 
and  accurate  global  snapshot  of  the  deadlock  cycle,  and  hence  the  deadlock  will 
be  detected.  Deadlocks  in  the  second  category  are  those  in  which  all  the  tran- 
sactions and  resources  involved  are  at  one  site,  but  the  transactions  involv 
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may  have  locked  resources  at  other  sites  before  creating  the  agent  at  this  site. 
The  argument  to  show  that  ail  deadlocks  in  this  category  will  be  detected  by  the 
proposed  algorithm  is  essentially  the  same  as  the  one  used  for  the  first 
category.  Since  ail  the  transactions  involved  in  the  deadlock  are  currently  at 
this  site,  their  Lock  Histories  are  complete  and  accurate  in  so  far  as  they  per- 
tain to  the  deadlock  cycle.  It  is  possible,  in  the  case  of  concurrent  execution  of 
a  transaction's  agents,  for  an  agent  involved  in  a  deadlock  to  be  unaware  of 
resources  locked  by  other  agents  of  that  transaction  which  are  executing  con- 
currently, and  will  probably  still  be  active.  The  only  difference  between  this 
case  and  the  preceding  is  that  the  WFGs  constructed  by  steps  2B2  and  2B6  may 
contain  information  about  other  locks  held  by  the  transactions  involved,  but  the 
information  concerning  the  deadlock  cycle  will  be  present.  Deadlocks  in  the 
third  category  will  be  detected  b]-  level  1  because  a  single  Lock  Table  at  each 
site  holds  sufficient  information  to  detect  a  deadlock  cycle.  If  the  migrations 
occur  simultaneously,  the  "Next"  field  of  the  Lock  Table  of  the  requested 
resource  would  sho^v  an  Intention  Lock  on  the  other  resource,  and  this  cycle 
would  be  detected  by  step  2B2.  If  the  migrations  occurred  sequentially,  the 
second  transaction  would,  before  migrating,  place  an  Intention  Lock  in  the  Lock 
Table  of  its  last  locked  resource.  The  level  1  check  of  step  IB  would  cause  a  WFG 
to  be  constructed  which  would  reveal  the  deadlock  cycle.  The  fourth  category  of 
deadlock  cycles  is  a  generalization  of  the  third.  Deadlock  cycles  in  this  category 
may  involve  any  number  of  transactions  and  resources  at  any  number  of  sites. 
A  record  is  always  kept  of  the  site  to  which  a  transaction  has  migrated  (in  the 
"Next"  field  of  it's  last  locked  resource  at  the  current  site.)  If  level  2  cannot 
detect  the  cycle  in  step  2B6  with  information  at  that  site,  level  3  causes  a  WFS 
containing  this  site's  information  to  be  sent  to  the  site  to  which  the  transaction 
has  migrated  if  the  transaction  which  has  migrated  has  a  lower  unique  identifier 
than  the  first  transaction  in  the  substring.    Steps  3  and  4  cause  this  process  to 
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be  continued,  with  each  site  adding  additional  information,  until  a  site  contains 
enough  information  to  detect  a  deadlock  cycle  or  determine  that  no  deadlock 
exists,  reg  ardless  of  the  number  of  migrations  made  by  a  transaction.  To  show 
that,  this  process  will  continue  until  the  deadlock  is  detected,  we  refer  to  the 
proof  in  [OBE82],  since  the  optimization  in  the  proposed  and  in  the  Obermarck's 
algorithm  is  essentially  the  same.  False  deadlocks  are  an  anomaly  where  a  non- 
existent deadlock  cycle  is  detected  by  a  deadlock  detection  algorithm,  and  are 
usually  a  -esult  of  incorrect  or  obsolete  information  Since  the  proposed  algo- 
rithm uses  only  the  latest  copy  of  a  transaction's  Lock  History  for  deadlock 
detection  purposes,  the  information  used  cannot  be  incorrect  in  the  sense  of 
invalid  entries,  although  it  may  be  incomplete.  This  means  that  a  Wait-For  graph 
constructed  from  incomplete  versions  of  Lock  Histories  may  have  insufficient 
information  to  detect  a  deadlock  at  that  particular  level  of  detection  activity  or 
iteration  of  level  three  activity,  but  it  will  not  have  incorrect  information.  When 
a  transaction  which  has  agents  at  two  or  more  sites  commits  or  aborts,  however, 
it  i&  possible  that  the  commit  or  abort  messages  to  other  agents  of  that  transac- 
tion may  be  delayed.  Obviously,  a  transaction  which  is  ready  to  commit  cannot 
have  any  of  it's  agents  in  a  blocked  state  (and  therefore  in  a  possible  deadlock 
condition),  so  its  agents  can  either  be  only  active  or  inactive.  While  inactive 
agents  may  be  being  waited  for  by  agents  of  other  transactions,  no  Lock  History 
or  Lock  Table  can  show  that  an  agent  of  the  transaction  which  is  about  to  com- 
mit is  waiting  for  another  transaction,  so  no  false  deadlocks  can  exist.  There- 
fore only  the  possibility  of  a  transaction  which  is  in  the  process  of  aborting  and 
thus  causing  a  false  deadlock  to  be  detected  must  be  considered.  Suppose  an 
agent  of  a  transaction  decides  to  abort,  but  before  its  abort  message  reaches 
another  agent  of  that  transaction,  a  deadlock  is  found  involving  that  transaction. 
Technically,  this  could  be  considered  a  false  deadlock,  since  one  of  the  transac- 
tions   involved  has   aborted,    probably  breaking   the   deadlock   cycle.     If   the 
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deadlock  cycle  is  complex,  and  the  proposed  algorithm  is  performing  level  two 
or  three  detection  activity,  the  delays  introduced  in  steps  2B4  and  236c  should 
allow  the  abort  message  to  arrive.  For  what  we  believe  to  be  the  rare 
occurences  where  the  abort  message  does  not  arrive,  it  would  probably  be  more 
efficient  to  let  the  deadlock  detection  algorithm  resolve  the  (false)  deadlock 
rather  than  having  the  algorithm  perform  some  explicit  action  (such  as  delaying 
before  resolving  any  detected  deadlock  cycle)  each  time  it  detects  a  deadlock, 

IV.   PERFORMANCE  ANALYSIS 

To  check  the  efficiency  (in  terms  of  inter-site  messages)  of  the  algorithm,  it  was 
analyzed  in  several  deadlock  scenarios.  The  algorithm  of  Obermarck  [QBE88J 
was  also  analyzed  in  these  scenarios.  Obermarck' s  algorithm  was  chosen  for 
this  comparison  because  it  is  being  implemented  in  IBM's  developmental  distri- 
buted database  system,  System  R*  and  because  its  performance  has  been  shown 
[0BE82]  superior  to  other  deadlock  detection  algorithms.  Since  the  majority  of 
deadlocks  which  will  occur  will  be  of  length  two  or  three,  three  test  cases  involv- 
ing deadlock  cycles  of  those  lengths  will  be  used  for  the  comparison.  It  is 
assumed  that  the  transactions  are  lexically  ordered  Ti  <  T2  <  T3.  These  cases 
are  shown  in  Figure  5.  Tl  originated  at  site  A  and  holds  a  lock  on  Rl,  and  T2  ori- 
ginated at  site  B  and  holds  a  lock  on  R2.  In  cases  two  and  three,  T3  originated  at 
site  C  and  holds  a  lock  on  R3.  In  case  one,  Tl  has  migrated  to  site  B  and 
requested  R2,  while  T2  has  migrated  to  site  A  and  requested  Rl.  In  case  two,  Tl 
has  migrated  to  site  B  and  requested  R2,  T2  has  migrated  to  site  C  and 
requested  R3,  and  T3  has  migrated  to  site  A  and  requested  Rl.  In  case  three,  Tl 
has  migrated  to  site  C  and  requested  R3,  T2  has  migrated  to  site  A  and 
requested  Rl,  and  T3  has  migrated  to  site  B  and  requested  R2. 

For  case  one,  where  the  deadlock  cycle  is  of  length  two,  the  proposed  algorithm 
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Fig.  5  —  Deadlock  cycles  used  in  performance  analysis 

requires  no  additional  messages  for  deadlock  detection,  while  Obermarck's  algo- 
rithm requires  one  message.  For  case  two,  with  a  deadlock  cycle  of  length 
three,  Obermarck's  algorithm  requires  two  messages.  The  number  of  messages 
required  by  the  proposed  algorithm  is  dependent  on  the  timing  of  the  transac- 
tion migrations.  If  the  migrations  occur  at  different  times  (i.e.,  sequentially),  no 
messages  are  required.  If,  however,  the  migrations  happen  to  occur  simultane- 
ously, only  one  message  is  generated  because  of  the  optimization.  A  similar 
situation  occurs  in  case  three.  If  the  migrations  occur  simultaneously,  two  mes- 
sages will  be  generated  by  the  proposed  algorithm,  although  one  of  these  mes- 
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sages  i:s  redundant,  Le.,  any  one  message  is  sufficient  to  detect  deadlock.  If 
transaction  migrations  occur  at  different  times  (i.e.,  sequentially)  then  no  mes- 
sages are  required.  Obermarck's  algorithm  requires  three  messages,  regardless 
of  the  timing  of  the  migrations.  As  pointed  out  in  [0BEB2]  it  is  apparent  that  in 
the  overwhelming  majority  of  cases  the  global  deadlocks  are  of  cycles  of  length 
two  involving  two  sites.  No  messages  are  required  to  detect  direct  global 
deadlocks  of  cycle  length  two  by  the  proposed  algorithm.  In  order  to  provide 
the  evaluation  of  both  algorithms  for  global  deadlocks  with  cycle  length  n  >  2  we 
assume  that  n  nonlocal  (or  global)  transactions  are  involved  in  the  global 
deadlock  such  that  at  each  of  n  sites  only  one  transaction  is  blocked  by  another 
transaction  and  each  transaction  needs  to  execute  only  at  two  sites.  Then  the 
number  of  messages  needed  by  the  proposed  algorithm  for  the  worst  case 
scenario  (when  all  the  transactions  involved  migrate  simultaneously)  can  be 
shown  to  be  N-l,  where  N  =%/ (n-k).  Under  the  same  circumstances  it  can  be 
shown  that  Obermarck's  algorithm  [OBE82]  requires  N  messages  regardless  of 
sequencing  of  transaction  migrations,  i.e.,  the  number  of  messages  depends  only 
on.  the  number  of  transactions  involved  in  the  deadlock.  Thus  for  a  cycle  of 
length  three,  the  number  of  messages  required  for  the  worst  case  would  be  two 
for  the  proposed  algorithm  and  the  Obermarck's  algorithm  would  require  tree 
messages.  For  a  cycle  of  length  four,  the  worst  case  would  require  five  messages 
under  the  proposed  algorithm  vs.  cycle  of  length  five,  nine  messages  would  be 
required.  We  want  to  stress  again  that  the  worst  case  performance  of  the  pro- 
posed algorithm  only  occurs,  however,  when  all  transactions  involved  migrate 
simultaneously,  and  the  lexical  ordering  of  the  transactions  is  such  that  n-l 
messages  are  sent  on  the  first  iteration  It  is  safe  to  assume  that  the  worst  case 
scenario  does  not  always  occur  with  each  global  deadlock  and  therefore  the  real 
performance  of  the  proposed  algorithm  is  expected  to  be  better  than  we  stated 
here.   However,  we  must  point  out  that  the  decrease  in  the  number  of  inter-site 
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messages  comes  at  the  cost  of  slightly  more  complex  lock  tables  and  at  the  cost 
of  each  transaction  carrying  with  it  slightly  mere  information  (its  Lock  History). 
The  amount  of  time  used  in  level  one  activity  is  minimal,  since  only  a  single 
resource's  Lock  Table  is  used  to  determine  the  set  of  transactions  "whose  Lock 
Histories  must  be  combined.  Even  with  Irvel  two.  the  time  required  to  construct 
a  WFG  using  all  Wait  For  information  at  a  site  sfc.ould  take  no  longer  than  the  con- 
struction of  a  WFG  in  Obermarck's  algorithm.  In  [OBE82],  Obermarck  does  not 
discuss  the  factors  which  trigger  deadlock  detection,  but  for  this  analysis,  it  is 
assumed  that  it  is  triggered  X  units  of  time  after  a  transaction  waits  for  a 
resource.  His  algorithm  constructs  a  WFG  at.  each  iteration  of  the  deadlock 
detection  cycle,  regardless  of  the  potential  size  of  the  cycle.  Since  the  proposed 
algorithm  performs  a  comparable  construction  only  when  cycles  of  length  two 
have  essentially  been  eliminated  as  a  possibility,  it  appears  that  the  proposed 
algorithm  will  require  less  time  to  execute  whenever  it  is  invoked. 

V.   CONCLUSIONS 

The  proposed  algorithm  has  been  shown  to  be  able  to  detect  deadlock  with 
smaller  number  of  inter-site  messages  tr^an  any  existing  algorithm  for  deadlock 
detection  in  distributed  computing  systems.  We  have  shown  that  for  the 
deadlock  scenarios  analyzed  in  this  paper  the  proposed  algorithm  requires  from 
zero  to  N-l  (where  N  =^(n-k))  messages  to  detect  a  global  deadlock,  where  n  is 
the  number  of  transactions  and  sites  involved  in  the  deadlock  cycle.  It  requires 
no  messages  when  the  transaction  migrations  leading  to  the  deadlock  occur 
sequentially.  This  is  because  when  a  transaction  migrates,  it  "brings  along"  a 
pertinent  wait-for  information  from  its  current  site.  The  worst  case  for  the  pro- 
posed algorithm  is  when  the  transactions  involved  migrate  simultaneously.  This 
can  result  in  as  many  as  N-l  messages,  depending  on  the  ordering  of  the  unique 
transaction    identifiers.     Obermarck's    algorithm    for    this    case    requires    N 


21 


messages,  which  is  always  one  message  more  than  the  number  required  by  the 
proposed  algorithm.  The  reason  that  the  proposed  algorithm  requires  one  less 
iteration  of  message  passing  is  because  the  Lock  Histories  of  each  transaction 
are  brought  along  with  the  transaction  when  it  migrates,  and  thus  each  site  has 
more  information  than  the  sites  would  have  using  Obermarck's  algorithm.  The 
most  important  point  is  that  the  proposed  algorithm  can  detect  the  most  fre- 
quent deadlocks  without  any  inter-site  messages.  The  proposed  algorithm 
requires  no  inter-site  messages  for  direct  deadlocks  of  cycle  length  two  involv- 
ing two  sites,  or  for  deadlocks  of  cycle  length  >  2  when  a)  a  sequential  migration 
of  transactions  in  order  of  their  lexically  ordered  unique  identifiers  has  occured 
regardless  of  the  number  of  transactions  or  sites  involved  or  b)  the  deadlock  is 
direct  and  involves  only  two  sites  where  at  one  site  only  two  transactions  conflict 
and  an  arbitrary  number  it  transactions  conflict  at  the  other  site.  For  all  other 
types  of  deadlocks  the  proposed  algorithm  requires  one  less  message  than 
Obermarck's  algorithm.  "Tie  proposed  algorithm  could  be  modified  by  combin- 
ing levels  one  and  two,  if  the  number  of  resources  and  transactions  in  the  sys- 
tem are  small,  and  therefore  the  cost  of  creating  WFG's  at  level  2  would  be  com- 
parable to  the  cost  of  the  level  1  WFG  construction.  The  cost  of  construction  of 
the  WFG's  used  by  the  algorithm  could  be  saved  by  not  constructing  them  at  all, 
but  merely  examining  the  WFS's  and  Lock  Histories,  since  all  required  informa- 
tion is  contained  in  them.  The  delays  which  have  been  built-in  to  the  algorithm 
can  be  adjusted  empirically  to  determine  the  optimum  delays  for  a  particular 
implementation 
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